| Oracle TimesTen In-Memory Database Java開発者およびリファレンス・ガイド
リリース7.0 E05166-01 |
|
 前へ |
 次へ |
Javaアプリケーションは、JMS/XLA APIを使用してTimesTenからイベント通知を受信できます。JMS/XLAは、JMSパブリッシュ・サブスクライブ・インタフェースを使用してXLA更新へのアクセスを提供します。
XLAへの接続を提供するJMS Sessionを確立して永続サブスクライバ（TopicSubscriber）を作成し、更新をサブスクライブします。このサブスクライバを使用してメッセージを同時に受信および処理したり、リスナー（MessageListener）を実装して非同期に更新を処理できます。
JMS/XLAは、ローカル・データ・ストアを監視するアプリケーション用に設計されています。TimesTenおよび通知を受信するアプリケーションは、同じマシン上に存在している必要があります。
| 注意: | JMS/XLA APIでは、永続モードのXLAがサポートされています。このモードでは、XLAによって更新レコードがトランザクション・ログ・バッファまたはログ・ファイルから直接取得されるため、それらの更新レコードは読み取られるまで使用可能です。また、永続モードのXLAを使用すると、複数のリーダーでトランザクション・ログの更新に同時にアクセスできます。 |
この項の内容は次のとおりです。
アプリケーションによってTimesTenデータ・ストアが変更されると、TimesTenは、データ・ストアおよびトランザクション・コミットなどの他のイベントに対して行われた変更を示すログ・レコードを生成します。
生成される新しいログ・レコードは、常にログ・バッファの最後に書き込まれます。ディスク・ベースのロギングがデータ・ストアに対して有効になっている場合は、メモリー内のログ・バッファからディスク上のログ・ファイルに、ログ・レコードが定期的にバッチでフラッシュされます。
アプリケーションで、XLAを使用し、TimesTenデータ・ストアへの変更に関してトランザクション・ログを監視できます。XLAは、トランザクション・ログ全体を読み取り、ログ・レコードをフィルタ処理し、目的の表および列への変更が含まれているトランザクション・レコードのリストをXLAアプリケーションに配信します。
XLAは、レコードをディスクリート・トランザクションにソートします。複数のアプリケーションが同時にデータ・ストアを更新している場合、異なるアプリケーションのログ・レコードがログに交互配置されます。
XLAは、特定のトランザクションに関連するすべてのログ・レコードを透過的に抽出し、それらを連続するリストにしてアプリケーションに配信します。
コミット済のトランザクションのレコードのみが返されます。コミット済のレコードは、最後のコミット・レコードがトランザクション・ログに書き込まれる順序で返されます。コミットされていないデータ・ストアへの変更に関連するレコードは、XLAによってフィルタ処理されます。
変更が行われ、その後にロールバックされた場合、強制終了されたトランザクションのレコードはアプリケーションに配信されません。
これらのXLAの基本概念のほぼすべてを例3.1に示し、次にそれぞれの内容を箇条書きで示します。
図3.1に示すトランザクション・ログを例として考えてみます。
この例では、トランザクション・ログに次のレコードが含まれています。
CT1 - アプリケーションCは、表Wの行1を値7.7で更新
BT1 - アプリケーションBは、表Xの行3を値2で更新
CT2 - アプリケーションCは、表Wの行9を値5.6で更新
BT2 - アプリケーションBは、表Yの行2を値XYZで更新
AT1 - アプリケーションAは、表Zの行1を値3で更新
AT2 - アプリケーションAは、表Zの行3を値4で更新
BT3 - アプリケーションBがトランザクションをコミット
AT3 - アプリケーションAがトランザクションをロールバック
CT3 - アプリケーションCがトランザクションをコミット
表W、YおよびZへの変更を検出するように設定されているXLAアプリケーションでは次のようになります。
BT2およびBT3 - 表Yの行2を値XYZで更新し、コミット
CT1 - 表Wの行1を値7.7で更新
CT2およびCT3 - 表Wの行9を値5.6で更新し、コミット
この例では、次のことが示されています。
XLAを使用すると、表およびマテリアライズド・ビューの両方への変更を追跡できます。マテリアライズド・ビューによって、複数のディテール表内の選択した行および列への変更を追跡できる単一のソースが提供されます。マテリアライズド・ビューがない場合は、XLAアプリケーションで、すべてのディテール表の更新レコード（アプリケーションにとって重要ではない行および列への更新が反映されているレコードを含む）に対して監視およびフィルタ処理を行う必要があります。
一般に、表またはマテリアライズド・ビューへの変更を追跡するために使用するXLAメカニズムの間に処理上の違いはありません。
XLAに接続するには、特定のデータ・ストアに対応するJMSトピックへの接続を確立します。JMS/XLA構成ファイルでは、トピック名とデータ・ストア間のマッピングが提供されます。
デフォルトでは、JMS/XLAは、現在の作業ディレクトリでjmsxla.xmlという構成ファイルを検索します。そのファイルに別の名前または場所を使用する場合は、InitialContextクラスに環境変数の一部として指定し、その場所をCLASSPATHに追加する必要があります。ファイル名をInitialContextクラスに環境変数の一部として指定するには、例3.2のようなコードを使用します。
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.timesten.dataserver.jmsxla.SimpleInitialContextFactory");
env.put(XlaConstants.CONFIG_FILE_NAME, "/newlocation.xml");
InitialContext ic = new InitialContext(env);
XlaConstants.CONFIG_FILE_NAMEが設定されている場合、通常、JMS/XLA APIでは、クラス・ローダーを使用してJMS/XLA構成ファイルを検索します。例3.2では、JMS/XLA APIは、CLASSPATH環境変数で指定されている場所と、CLASSPATH環境変数で指定されているJARファイル内の最上位のディレクトリにあるnewlocation.xmlファイルを検索します。
また、JMS/XLA構成ファイルは、例3.3に示すようにサブディレクトリに配置することもできます。
env.put(XlaConstants.CONFIG_FILE_NAME,
"/com/mycompany/myapplication/deepinside.xml");
例3.3では、JMS/XLA APIは、CLASSPATH環境変数で指定されている場所と、CLASSPATH環境変数で指定されているjarファイル内のcom/mycompany/myapplicationサブディレクトリにあるdeepinside.xmlファイルを検索します。
JMS/XLA APIでは、最初に見つかった構成ファイルを使用します。
構成ファイル内のトピック定義は、名前、JDBC接続文字列、および1回で取得する更新数を指定するプリフェッチ値で構成されています。
たとえば、例3.4に示す構成ファイルでは、DemoDataStoreピックがTestDB DSNにマップされています。
<xlaconfig>
<topics>
<topic name="DemoDataStore"
connectionString="jdbc:timesten:direct:DSN=TestDB"
xlaPrefetch="100"
/>
</topics>
</xlaconfig>
アプリケーションは、JMS MapMessageオブジェクトとしてXLA更新を受け取ります。MapMessageには、XLA更新ヘッダー内のフィールドに対応する一連の名前/値ペアが含まれています。
MapMessage取得メソッドを使用してメッセージ・フィールドにアクセスできます。getMapNamesメソッドは、メッセージ内のすべてのフィールドの名前を含むEnumerationを返します。名前ごとにメッセージから個々のフィールドを取得できます。予約されたすべてのフィールド名は、__TYPEのように2つのアンダースコアで始まります。
すべての更新メッセージには、メッセージに含まれている更新のタイプを示す__TYPEフィールドがあります。タイプは、整数値で指定されています。整数タイプと比較するために、com.timesten.dataserver.jmsxla.XlaConstantsに定義されている定数を使用できます。表3.1に、サポートされているタイプを示します。
XLA更新メッセージの内容の詳細は、「XLA MapMessageの内容」を参照してください。
XLAブックマークは、トランザクション・ログ内のXLAサブスクライバ・アプリケーションの読取り位置にマークを付けます。ブックマークによって永続サブスクリプションが容易になり、アプリケーションはトピックから切断した後、読取りを中断した時点から、更新の受信を継続するために再接続できます。
XLAのメッセージ・コンシューマを作成する場合は、永続TopicSubscriberを使用します。サブスクライバを作成するときに指定するサブスクリプション識別子は、XLAブックマーク名として使用されます。表に対するXLAパブリッシングを開始および停止するためにJDBCを介して組込みプロシージャttXlaSubscribeおよびttXlaUnsubscribeを使用する場合は、使用するブックマークの名前を明示的に指定します。
応答を受信すると、ブックマークは最終読取り位置にリセットされます。更新メッセージが確認される方法の詳細は、「XLA応答モード」を参照してください。
JMS Sessionでサブスクライブ解除をコールすることによって、永続サブスクリプションを削除できます。これにより、対応するXLAブックマークが削除され、再接続するときに新規のサブスクリプションが強制的に作成されます。詳細は、「ブックマークの削除」を参照してください。
XLAの応答メカニズムは、アプリケーションがメッセージを受信するだけでなく、メッセージを正常に処理できるように設計されています。永続的に更新に応答すると、アプリケーションのXLAブックマークは、読み取られた最終レコードにリセットされます。これにより、以前に返されたレコードが再度読み取られることを回避できます。また、アプリケーションがXLAに再接続したときにブックマークが再利用された場合、以前に応答されたレコードをアプリケーションが受信しないようにすることもできます。
JMS/XLAは、XLA更新メッセージに自動的に応答します。また、アプリケーションは、応答するメッセージを明示的に選択できます。Sessionを作成したときに、更新の応答方法を指定します。
JMS/XLAでは、次の3つの応答方法がサポートされています。
xlaprefetch属性は無視されます）。xlaprefetch属性に基づいてレコードをプリフェッチし、プリフェッチされたブロック内の最終レコードが読み取られると応答を送信します。プリフェッチされたすべてのレコードを読み取る前にアプリケーションに障害が発生すると、ブロック内のすべてのレコードは、アプリケーションの再起動時にアプリケーションに渡されます。 MapMessageへの応答をコールすることによって更新メッセージの受信を確認します。CLIENT_ACKNOWLEDGEモードでは、JMS/XLAはトピックに指定されているxlaprefetch属性に基づいてレコードをプリフェッチします。 複数の更新レコードを一度にプリフェッチする処理は、XLAから各更新レコードを個々に取得する処理より効率的です。AUTO_ACKNOWLEDGEモードを使用すると、更新がプリフェッチされないため、他のモードよりも時間がかかります。可能な場合は、更新を重複して行うことができるようにアプリケーションを設計してください。これによって、DUPS_OK_ACKNOWLEDGEの使用、または更新の明示的な確認が可能になります。各メッセージが個々に確認されないようにすることができる場合、明示的に更新を確認すると、最も高いパフォーマンスを得ることができます。
XLA更新を明示的に確認するには、更新メッセージに対する確認をコールします。メッセージを暗黙的に確認すると、以前のすべてのメッセージが確認されます。通常は、確認と確認の間に、複数の更新メッセージを受信および処理します。CLIENT_ACKNOWLEDGEモードを使用していて、永続サブスクリプションを将来再利用する場合は、終了する前に、確認をコールして最後に読み取られた位置にブックマークを再設定する必要があります。
